home *** CD-ROM | disk | FTP | other *** search
/ HPAVC / HPAVC CD-ROM.iso / SS0288.ZIP / SS0288_3.TXT < prev    next >
Text File  |  1992-06-01  |  31KB  |  810 lines

  1. 88H LZEXT--LAZY EXTERN RECORD (COMMENT CLASS A9)
  2. ================================================
  3.  
  4. Description
  5. -----------
  6.  
  7. This record marks a set of external names as "lazy," and for every
  8. lazy extern, the record associates another external name to use as the
  9. default resolution.
  10.  
  11. History
  12. -------
  13.  
  14. This comment class and subtype is a Microsoft extension added for C
  15. 7.0, but was not implemented in the C 7.0 linker.
  16.  
  17. Record Format
  18. -------------
  19.  
  20. The subrecord format is:
  21.  
  22.    1      1 or 2           1 or 2
  23.    A9     Lazy EXTDEF      Default Resolution
  24.           Index            EXTDEF Index
  25.           <---------------repeated------------->
  26.  
  27. The Lazy EXTDEF Index field is the 1- or 2-byte index to the EXTDEF of
  28. the extern that is lazy.
  29.  
  30. The Default Resolution EXTDEF Index field is the 1- or 2-byte index to
  31. the EXTDEF of the extern that will be used to resolve the extern if no
  32. "stronger" link is found to resolve it.
  33.   
  34.   NOTES
  35.   
  36.   There are two ways to cancel the "laziness" of a lazy extern; both
  37.   result in the extern becoming a "strong" extern (the same as an
  38.   EXTDEF.) They are:
  39.   
  40.     - If a PUBDEF for the lazy extern is linked in
  41.     - If an EXTDEF for the lazy extern is found in another module
  42.       (including libraries)
  43.   
  44.   If a lazy extern becomes strong, it must be resolved with a matching
  45.   PUBDEF, just like a regular EXTDEF. If a lazy extern has not become
  46.   strong by the end of the linking process, then the default
  47.   resolution is used.
  48.   
  49.   If two weak externs for the same symbol in different modules have
  50.   differing default resolutions, LINK will emit a warning.
  51.   
  52.   Unlike weak externs, lazy externs do query libraries for resolution;
  53.   if an extern is still lazy when libraries are searched, it stays
  54.   lazy and gets the default resolution.
  55.   
  56. 88H PHARLAP FORMAT RECORD (COMMENT CLASS AA)
  57. ============================================
  58.  
  59. Description
  60. -----------
  61.  
  62. The OMF extension designed by PharLap is called "Easy OMF-386."
  63. Changes to the affected record types are described in this section.
  64.  
  65. Most modifications involve only a substitution of 32-bit (4-byte)
  66. fields for what were formerly 16-bit (2-byte) fields. In the two cases
  67. where the changes involve more than just a field size (in the SEGDEF
  68. and FIXUPP records), the information is mentioned in this section, but
  69. complete details are given in the sections describing the specific
  70. records.
  71.  
  72. History
  73. -------
  74.  
  75. This format is described as "obsolete" in the expectation that
  76. negotiations between Microsoft and PharLap will result in convergence
  77. to the new "standard." However, its obsolescence needs to be verified.
  78. When the new standard is agreed upon, Microsoft encourages you to
  79. adopt it.
  80.  
  81. Record Format
  82. -------------
  83.  
  84. The format of the comment's subrecord is:
  85.  
  86.    AA     "80386"
  87.      
  88.      
  89.   NOTES
  90.   
  91.   The AA comment record should come immediately after the sole THEADR
  92.   record. Presence of the comment record indicates that the following
  93.   other record types have fields that are expanded from 16-bit to 32-
  94.   bit values:
  95.   
  96.      SEGDEF Offset field and Segment Length field
  97.  
  98.      PUBDEF Public Offset field
  99.  
  100.      LEDATA Enumerated Data Offset field
  101.  
  102.      LIDATA Iterated Data Offset field (note that the Repeat Count
  103.             field is still 16 bits)
  104.  
  105.      FIXUPP Target Displacement field in an explicit FIXUP subrecord
  106.  
  107.      BLKDEF Return Address Offset field
  108.  
  109.      LINNUM Line Number Offset field
  110.  
  111.      MODEND Target Displacement field
  112.  
  113.   FIXUPP records have the added LOCATION values of 5 and 6, which
  114.   conflict with the Microsoft 32-bit extensions to this field. See the
  115.   FIXUPP section of this document for details.
  116.   
  117.   SEGDEF records have added alignment values (for 4-byte alignment and
  118.   4K alignment) and an added optional byte at the end that contains
  119.   the Use16/Use32 bit flag and access attributes (read/write/execute)
  120.   for the segment. The alignment values are the same as Microsoft's 32-
  121.   bit extensions to the field, but the attributes stored in the added
  122.   byte conflict with Microsoft's way of specifying those attributes.
  123.   See the SEGDEF sectionof this document for details.
  124.   
  125.   
  126. 8AH OR 8BH MODEND--MODULE END RECORD
  127. ====================================
  128.  
  129. Description
  130. -----------
  131.  
  132. The MODEND record denotes the end of an object module. It also
  133. indicates whether the object module contains the main routine in a
  134. program, and it can optionally contain a reference to a program's
  135. entry point.
  136.  
  137. History
  138. -------
  139.  
  140. Record type 8BH is new for LINK386; it has a Target Displacement field
  141. of 32 bits rather than 16 bytes.
  142.  
  143. An IBM extension to this record type (initial values for segment
  144. registers) was proposed for LINK386 but was never implemented.
  145.  
  146. Record Format
  147. -------------
  148.    
  149.   1  2       1      1         1 or 2  1 or 2   2 or 4     1
  150.  8A  Record  Module End Data  Frame   Target   Target     Checksum
  151.   or Length  Type             Datum   Datum    Displace-  
  152.  8B                                            ment
  153.                     <-Start Address subfield, conditional->
  154.  
  155. where:
  156.    
  157.    Module Type Field
  158.    
  159.    The Module Type byte is bit significant; its layout is
  160.    
  161.       MATTR         Segment                                      
  162.       Main  Start   Bit      0          0       0       0       X
  163.       <--2 bits-->                                  
  164.  
  165.   where:
  166.  
  167.       MATTR           Is a 2-bit field.
  168.                       
  169.       Main            Is set if the module is a main program
  170.                       module.
  171.                       
  172.       Start           Is set if the module contains a start
  173.                       address; if this bit is set, the field
  174.                       starting with the End Data byte is present
  175.                       and specifies the start address.
  176.                       
  177.       Segment Bit     Is reserved by IBM. Only 0 is supported by
  178.                       MS-DOS and OS/2.
  179.                       
  180.       X               Is set if the Start Address subfield
  181.                       contains a relocatable address reference
  182.                       that LINK must fix up. (The Intel
  183.                       specification allows this bit to be 0, to
  184.                       indicate that the start address is an
  185.                       absolute physical address that is stored as
  186.                       a 16-bit frame number and 16-bit offset,
  187.                       but this capability is not supported by
  188.                       LINK.) This bit should always be set;
  189.                       however, the value will be ignored.
  190.                       
  191.       Start Address   The Start Address subfield is present only
  192.                       if the Start bit in the Module Type byte is
  193.                       set. Its format is identical to the Fix
  194.                       Data, Frame Datum, Target Datum, and Target
  195.                       Displacement fields in a FIXUP subrecord of
  196.                       a FIXUPP record. Bit 2 of the End Data
  197.                       field, which corresponds to the P bit in a
  198.                       Fix Data field, must be 0. The Target
  199.                       Displacement field (if present) is a 4-byte
  200.                       field if the record type is 8BH and a 2-
  201.                       byte field otherwise. This value provides
  202.                       the initial contents of CS:(E)IP.
  203.                       
  204.                       If overlays are used, the start address
  205.                       must be given in the MODEND record of the
  206.                       root module.
  207.                       
  208.   
  209.   NOTES
  210.   
  211.   A MODEND record can appear only as the last record in an object
  212.   module.
  213.   
  214.   It is assumed that the Link Pass Separator comment record (COMENT
  215.   A2, subtype 01) will not be present in a module whose MODEND record
  216.   contains a program starting address. If there are overlays, LINK
  217.   needs to see the starting address on Pass 1 to define the symbol
  218.   $$MAIN.
  219.  
  220. Examples
  221. --------
  222.  
  223. Consider the MODEND record of a simple HELLO.ASM program:
  224.  
  225.        0  1   2  3   4  5   6  7   8  9 A B C D E F 
  226.   0000 8A 07  00 C1  00 01  01 00  00                AC.....
  227.  
  228. Byte 00H contains 8AH, indicating a MODEND record.
  229.  
  230. Bytes 01-02H contain 0007H, the length of the remainder of the record.
  231.  
  232. Byte 03H contains 0C1H (11000001B). Bit 7 is set to 1, indicating that
  233. this module is the main module of the program. Bit 6 is set to 1,
  234. indicating that a Start Address subfield is present. Bit 0 is set to
  235. 1, indicating that the address referenced in the Start Address
  236. subfield must be fixed up by LINK.
  237.  
  238. Byte 04H (End Data in the Start Address subfield) contains 00H. As in
  239. a FIXUPP record, bit 7 indicates that the frame for this fixup is
  240. specified explicitly, and bits 6 through 4 indicate that a SEGDEF
  241. index specifies the frame. Bit 3 indicates that the target reference
  242. is also specified explicitly, and bits 2 through 0 indicate that a
  243. SEGDEF index also specifies the target. See also "9CH or 9DH FIXUPP--
  244. Fixup Record" in this document.
  245.  
  246. Byte 05H (Frame Datum in the Start Address subfield) contains 01H.
  247. This is a reference to the first SEGDEF record in the module, which in
  248. this example corresponds to the _TEXT segment. This reference tells
  249. LINK that the start address lies in the _TEXT segment of the module.
  250.  
  251. Byte 06H (Target Datum in the Start Address subfield) contains 01H.
  252. This also is a reference to the first SEGDEF record in the object
  253. module, which corresponds to the _TEXT segment. LINK uses the
  254. following Target Displacement field to determine where in the _TEXT
  255. segment the address lies.
  256.  
  257. Bytes 07-08H (Target Displacement in the Start Address subfield)
  258. contain 0000H. This is the offset (in bytes) of the start address.
  259.  
  260. Byte 09H contains the Checksum field, 0ACH.
  261.  
  262.  
  263. 8CH EXTDEF--EXTERNAL NAMES DEFINITION RECORD
  264. ============================================
  265.  
  266. Description
  267. -----------
  268.  
  269. The EXTDEF record contains a list of symbolic external references--
  270. that is, references to symbols defined in other object modules. The
  271. linker resolves external references by matching the symbols declared
  272. in EXTDEF records with symbols declared in PUBDEF records.
  273.  
  274. History
  275. -------
  276.  
  277. In the Intel specification and older linkers, the Type Index field was
  278. used as an index into TYPDEF records. This is no longer true; the
  279. field now encodes CodeView type information (see Appendix 1 for
  280. details.) LINK ignores the old style TYPDEF.
  281.  
  282. Record Format
  283. -------------
  284.    
  285.    1      2       1       <String Length>   1 or 2      1
  286.    8C     Record  String  External          Type Index  Checksum
  287.           Length  Length  Name String                   
  288.  
  289. This record provides a list of unresolved references, identified by
  290. name and with optional associated type information. The external names
  291. are ordered by occurrence jointly with the COMDEF and LEXTDEF records,
  292. and referenced by an index in other records (FIXUPP records); the name
  293. may not be null. Indexes start from 1.
  294.  
  295. String Length is a 1-byte field containing the length of the name
  296. field that follows it. LINK restricts the name length to a value
  297. between 1 and 7FH.
  298.  
  299. The Type Index field is encoded as an index field and contains
  300. proprietary CodeView-type information. At this time, the linker does
  301. not perform any type checking.
  302.   
  303.   NOTES
  304.   
  305.   For Microsoft compilers, all referenced functions of global scope
  306.   and all referenced variables explicitly declared "extern" will
  307.   generate an EXTDEF record.
  308.   
  309.   LINK imposes a limit of 1023 external names.
  310.   
  311.   Any EXTDEF records in an object module must appear before the FIXUPP
  312.   records that reference them.
  313.   
  314.   Resolution of an external reference is by name match (case
  315.   sensitive) and symbol type match. The search looks for a matching
  316.   name in the following sequence:
  317.     
  318.    1. Searches PUBDEF and COMDEF records.
  319.    
  320.    2.  If linking a segmented executable, searches imported names
  321.       (IMPDEF).
  322.    
  323.    3. If linking a segmented executable and not a DLL, searches for an
  324.       exported name (EXPDEF) with the same name--a self-imported
  325.       alias.
  326.    
  327.    4. Searches for the symbol name among undefined symbols. If the
  328.       reference is to a weak extern, the default resolution is used.
  329.       If the reference is to a strong extern, it's an undefined
  330.       external, and LINK generates an error.
  331.   
  332.   All external references must be resolved at link time (using the
  333.   above search order). Even though LINK produces an executable file
  334.   for an unsuccessful link session, an error bit is set in the header
  335.   that prevents the loader from running the executable.
  336.  
  337. Examples
  338. --------
  339.  
  340. Consider this EXTDEF record generated by the Microsoft C Compiler:
  341.  
  342.      0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F 
  343. 0000 8C 25 00 0A 5F 5F 61 63 72 74 75 73 65 64 00 05 .%.__acrtused..
  344. 0010 5F 6D 61 69 6E 00 05 5F 70 75 74 73 00 08 5F 5F _main.._puts..__ 
  345. 0020 63 68 6B 73 74 6B 00 A5                         chkstk..                      
  346.  
  347. Byte 00H contains 8CH, indicating that this is an EXTDEF record.
  348.  
  349. Bytes 01-02H contain 0025H, the length of the remainder of the record.
  350.  
  351. Bytes 03-26H contain a list of external references. The first
  352. reference starts in byte 03H, which contains 0AH, the length of the
  353. name __acrtused. The name itself follows in bytes 04-0DH. Byte 0EH
  354. contains 00H, which indicates that the symbol's type is not defined by
  355. any TYPDEF record in this object module. Bytes 0F-26H contain similar
  356. references to the external symbols _main, _puts, and __chkstk.
  357.  
  358. Byte 27H contains the Checksum field, 0A5H.
  359.  
  360.  
  361. 8EH TYPDEF--TYPE DEFINITION RECORD
  362. ==================================
  363.  
  364. Description
  365. -----------
  366.  
  367. The TYPDEF record contains details about the type of data represented
  368. by a name declared in a PUBDEF or an EXTDEF record. This information
  369. may be used by a linker to validate references to names, or it may be
  370. used by a debugger to display data according to type.
  371.  
  372. Although the original Intel specification allowed for many different
  373. type specifications, such as scalar, pointer, and mixed data
  374. structure, LINK used TYPDEF records to declare only communal
  375. variables. Communal variables represent globally shared memory areas--
  376. for example, FORTRAN common blocks or uninitialized public variables
  377. in C.
  378.  
  379. The size of a communal variable is declared explicitly in the TYPDEF
  380. record. If a communal variable has different sizes in different object
  381. modules, LINK uses the largest declared size when it generates an
  382. executable module.
  383.  
  384. History
  385. -------
  386.  
  387. Starting with Microsoft LINK version 3.5, the COMDEF record should be
  388. used for declaration of communal variables. However, for
  389. compatibility, later versions of LINK recognize TYPDEF records as well
  390. as COMDEF records.
  391.  
  392. Record Format
  393. -------------
  394.    
  395.    1   2          <variable>     1       <variable>  1
  396.    8E  Record     Name           0       Leaf        Checksum
  397.        Length                    (EN)    Descriptor  
  398.  
  399. The name field of a TYPDEF record is in <count, char> format and is
  400. always ignored. It is usually a 1-byte field containing a single 0
  401. byte.
  402.  
  403. The Eight-Leaf Descriptor field in the original Intel specification
  404. was a variable-length (and possibly repeated) field that contained as
  405. many as eight "leaves" that could be used to describe mixed data
  406. structures. Microsoft uses a stripped-down version of the Eight-Leaf
  407. Descriptor, of which the first byte, the EN byte, is always set to 0.
  408.  
  409. The Leaf Descriptor field is a variable-length field that describes
  410. the type and size of a variable. The two possible variable types are
  411. NEAR and FAR.
  412.  
  413. If the field describes a NEAR variable (one that can be referenced as
  414. an offset within a default data segment), the format of the Leaf
  415. Descriptor field is:
  416.  
  417.    1      1           <variable>
  418.    62H    Variable    Length in Bits
  419.           Type
  420.  
  421. The 1-byte field containing 62H signifies a NEAR variable.
  422.  
  423. The Variable Type field is a 1-byte field that specifies the variable
  424. type:
  425.    
  426.    77H    Array
  427.    79H    Structure
  428.    7BH    Scalar
  429.  
  430. This field must contain one of the three values given above, but the
  431. specific value is ignored by LINK.
  432.  
  433. The Length in Bits field is a variable-length field that indicates the
  434. size of the communal variable. Its format depends on the size it
  435. represents.
  436.  
  437. If the first byte of the size is 128 (80H) or less, then the size is
  438. that value. If the first byte of the size is 81H, then a 2-byte size
  439. follows. If the first byte of the size is 84H, then a 3-byte size
  440. follows. If the first byte of the size is 88H, then a 4-byte size
  441. follows.
  442.  
  443. If the Leaf Descriptor field describes a FAR variable (one that must
  444. be referenced with an explicit segment and offset), the format is:
  445.  
  446.    1      1           <variable>          <variable>
  447.    61H    Variable    Number of Elements  Element Type Index
  448.           Type (77H)                      
  449.  
  450. The 1-byte field containing 61H signifies a FAR variable.
  451.  
  452. The 1-byte variable type for a FAR communal variable is restricted to
  453. 77H (array). (As with the NEAR Variable Type field, LINK ignores this
  454. field, but it must have the value 77H.)
  455.  
  456. The Number of Elements field is a variable-length field that contains
  457. the number of elements in the array. It has the same format as the
  458. Length in Bits field in the Leaf Descriptor field for a NEAR variable.
  459.  
  460. The Element Type Index field is an index field that references a
  461. previous TYPDEF record. A value of 1 indicates the first TYPDEF record
  462. in the object module, a value of 2 indicates the second TYPDEF record,
  463. and so on. The TYPDEF record referenced must describe a NEAR variable.
  464. This way, the data type and size of the elements in the array can be
  465. determined.
  466.  
  467.   NOTE: LINK limits the number of TYPDEF records in an object module
  468.   to 256.
  469.  
  470. Examples
  471. --------
  472.  
  473. The following three examples of TYPDEF records were generated by
  474. Microsoft C Compiler version 3.0. (Later versions use COMDEF records.)
  475.  
  476. The first sample TYPDEF record corresponds to the public declaration:
  477.  
  478.    int   var;     /* 16-bit integer */
  479.  
  480. The TYPDEF record is:
  481.  
  482.         0  1   2  3   4  5  6  7  8  9  A  B   C D  E  F  
  483.   0000  8E 06  00 00  00 62 7B 10 7F                     .....b{..
  484.  
  485. Byte 00H contains 8EH, indicating that this is a TYPDEF record.
  486.  
  487. Bytes 01-02H contain 0006H, the length of the remainder of the record.
  488.  
  489. Byte 03H (the name field) contains 00H, a null name.
  490.  
  491. Bytes 04-07H represent the Eight-Leaf Descriptor field. The first byte
  492. of this field (byte 04H) contains 00H. The remaining bytes (bytes 05-
  493. 07H) represent the Leaf Descriptor field:
  494.    
  495.     - Byte 05H contains 62H, indicating that this TYPDEF record
  496.       describes a NEAR variable.
  497.  
  498.     - Byte 06H (the Variable Type field) contains 7BH, which describes
  499.       this variable as scalar.
  500.  
  501.     - Byte 07H (the Length in Bits field) contains 10H, the size of
  502.       the variable in bits.
  503.  
  504. Byte 08H contains the Checksum field, 7FH.
  505.  
  506. The next example demonstrates how the variable size contained in the
  507. Length in Bits field of the Leaf Descriptor field is formatted:
  508.  
  509.    char var2[32768];   /* 32 KB array */
  510.  
  511. The TYPDEF record is:
  512.  
  513.      0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  
  514. 0000 8E 09 00 00 00 62 7B 84 00 00 04 04           .....bc{.....
  515.  
  516. The Length in Bits field (bytes 07-0AH) starts with a byte containing
  517. 84H, which indicates that the actual size of the variable is
  518. represented as a 3-byte value (the following three bytes). Bytes 08-
  519. 0AH contain the value 040000H, the size of the 32K array in bits.
  520.  
  521. This third C statement, because it declares a FAR variable, causes two
  522. TYPDEF records to be generated:
  523.  
  524.    char far  var3[10][2][20];    /* 400-element FAR array*/
  525.  
  526. The two TYPDEF records are:
  527.  
  528.      0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F 
  529. 0000 8E 06 00 00 62 7B 08 87 8E 09 00 00 00 00 61 77 ....bc{......aw
  530. 0010 81 90 01 01 7E                                  .....|
  531.  
  532. Bytes 00-08H contain the first TYPDEF record, which defines the data
  533. type of the elements of the array (NEAR, scalar, 8 bits in size).
  534.  
  535. Bytes 09-14H contain the second TYPDEF record. The Leaf Descriptor
  536. field of this record declares that the variable is FAR (byte 0EH
  537. contains 61H) and an array (byte 0FH, the variable type, contains
  538. 77H).
  539.  
  540.   NOTE: Because this TYPDEF record describes a FAR variable, bytes 10-
  541.   12H represent a Number of Elements field. The first byte of the
  542.   field is 81H, indicating a 2-byte value, so the next two bytes
  543.   (bytes 11-12H) contain the number of elements in the array, 0190H
  544.   (400D).
  545.  
  546. Byte 13H (the Element Type Index field) contains 01H, which is a
  547. reference to the first TYPDEF record in the object module--in this
  548. example, the one in bytes 00-08H.
  549.  
  550.  
  551. 90H OR 91H PUBDEF--PUBLIC NAMES DEFINITION RECORD
  552. =================================================
  553.  
  554. Description
  555. -----------
  556.  
  557. The PUBDEF record contains a list of public names. It makes items
  558. defined in this object module available to satisfy external references
  559. in other modules with which it is bound or linked.
  560.  
  561. The symbols are also available for export if so indicated in an EXPDEF
  562. comment record.
  563.  
  564. History
  565. -------
  566.  
  567. Record type 91H is new for LINK386; it has a Public Offset field of 32
  568. bits rather than 16 bits.
  569.  
  570. Record Format
  571. -------------
  572.    
  573. 1   2       1 or 2 1 or 2   2      1      <String     2 or 4  1 or 2 1
  574.                        Length>
  575. --------------------------------------------------------------------------
  576. 90  Record Base   Base     Base   String  Public      Public  Type  Check
  577. or  Length Group  Segment  Frame  Length  Name String Offset  Index sum
  578. 91              
  579. --------------------------------------------------------------------------
  580.               <condi <-------------repeated------------------>                
  581.                tional>
  582.  
  583. Base Group, Base Segment, and Base Frame Fields
  584. -----------------------------------------------
  585.           
  586. The Base Group and Base Segment fields are indexes specifying
  587. previously defined SEGDEF and GRPDEF records. The group index may be
  588. 0, meaning that no group is associated with this PUBDEF record.
  589.  
  590. The Base Frame field is present only if the Base Segment field is 0,
  591. but the contents of the Base Frame field are always ignored by LINK.
  592.  
  593. The segment index is normally nonzero and no Base Frame field is
  594. present.
  595.  
  596. According to the Intel specification, if both the segment and group
  597. indexes are 0, the Base Frame field contains a 16-bit paragraph (when
  598. viewed as a linear address); this may be used to define public symbols
  599. that are absolute. Absolute addressing is not fully supported by LINK-
  600. -it can be used for read-only access to absolute memory locations;
  601. however, writing to absolute memory locations may not work in current
  602. linkers. This feature is so rarely used that it should be considered
  603. unsupported.
  604.  
  605. Public Name String, Public Offset, and Type Index Fields
  606. --------------------------------------------------------
  607.           
  608. The Public Name String field is in <count, char> form and cannot be
  609. null. Microsoft LINK restricts the maximum length of a public name to
  610. 255 bytes.
  611.  
  612. The Public Offset field is a 2- or 4-byte numeric field containing the
  613. offset of the location referred to by the public name. This offset is
  614. assumed to lie within the group, segment, or frame specified in the
  615. Base Group, Base Segment, or Base Frame fields.
  616.  
  617. The Type Index field is encoded in index format; it contains either
  618. proprietary CodeView-type information or an old-style TYPDEF index. If
  619. this index is 0, there is no associated type data. Old-style TYPDEF
  620. indexes are ignored by LINK. Current linkers perform no type checking.
  621.  
  622.   NOTES
  623.   
  624.   All defined functions and initialized global variables generate
  625.   PUBDEF records in Microsoft compilers. No PUBDEF record will be
  626.   generated, however, for instantiated inline functions in C++.
  627.   
  628.   Any PUBDEF records in an object module must appear after the GRPDEF
  629.   and SEGDEF records to which they refer. Because PUBDEF records are
  630.   not themselves referenced by any other type of object record, they
  631.   are generally placed near the end of an object module.
  632.   
  633.   Record type 90H uses 16-bit encoding of the Public Offset field, but
  634.   it is zero-extended to 32 bits if applied to Use32 segments.
  635.  
  636. Examples
  637. --------
  638. The following two examples show PUBDEF records created by MASM.
  639.  
  640. The first example is the record for the statement:
  641.    
  642.    PUBLIC    GAMMA
  643.    
  644. The PUBDEF record is:
  645.  
  646.      0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  
  647. 0000 90 0C 00 00 01 05 47 41 4D 4D 41 02 00 00 F9  .....GAMMA.....
  648.  
  649. Byte 00H contains 90H, indicating a PUBDEF record.
  650.  
  651. Bytes 01-02H contain 000CH, the length of the remainder of the record.
  652.  
  653. Bytes 03-04H represent the Base Group, Base Segment, and Base Frame
  654. fields. Byte 03H (the group index) contains 0, indicating that no
  655. group is associated with the name in this PUBDEF record. Byte 04H (the
  656. segment index) contains 1, a reference to the first SEGDEF record in
  657. the object module. This is the segment to which the name in this
  658. PUBDEF record refers.
  659.  
  660. Bytes 05-0AH represent the Public Name String field. Byte 05H contains
  661. 05H (the length of the name), and bytes 06-0AH contain the name
  662. itself, GAMMA.
  663.  
  664. Bytes 0B-0CH contain 0002H, the Public Offset field. The name GAMMA
  665. thus refers to the location that is offset two bytes from the
  666. beginning of the segment referenced by the Base Group, Base Segment,
  667. and Base Frame fields.
  668.  
  669. Byte 0DH is the Type Index field. The value of the Type Index field is
  670. 0, indicating that no data type is associated with the name GAMMA.
  671.  
  672. Byte 0EH contains the Checksum field, 0F9H.
  673.  
  674.  
  675. The next example is the PUBDEF record for the following absolute
  676. symbol declaration:
  677.    
  678.             PUBLIC    ALPHA
  679.    ALPHA    EQU       1234h
  680.    
  681. The PUBDEF record is:
  682.  
  683.      0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  
  684. 0000 90 0E 00 00 00 00 00 05 41 4C 50 48 41 34 12 00 ...ALPHA4...
  685. 0010 B1                
  686.  
  687. Bytes 03-06H (the Base Group, Base Segment, and Base Frame fields)
  688. contain a group index of 0 (byte 03H) and a segment index of 0 (byte
  689. 04H). Since both the group index and segment index are 0, a frame
  690. number also appears in the Base Group, Base Segment, and Base Frame
  691. fields. In this instance, the frame number (bytes 05-06H) also happens
  692. to be 0.
  693.  
  694. Bytes 07-0CH (the Public Name String field) contain the name ALPHA,
  695. preceded by its length.
  696.  
  697. Bytes 0D-0EH (the Public Offset field) contain 1234H. This is the
  698. value associated with the symbol ALPHA in the assembler EQU directive.
  699. If ALPHA is declared in another object module with the declaration
  700.  
  701.    EXTRN     ALPHA:ABS
  702.  
  703. any references to ALPHA in that object module are fixed up as absolute
  704. references to offset 1234H in frame 0. In other words, ALPHA would
  705. have the value 1234H.
  706.  
  707. Byte 0FH (the Type Index field) contains 0.
  708.  
  709.  
  710. 94H OR 95H LINNUM--LINE NUMBERS RECORD
  711. ======================================
  712.  
  713. Description
  714. -----------
  715.  
  716. The LINNUM record relates line numbers in source code to addresses in
  717. object code.
  718.  
  719. For instantiated inline functions in C 7.0, line numbers will be
  720. output in LINSYM records with a reference to the function name instead
  721. of the segment.
  722.  
  723. History
  724. -------
  725.  
  726. Record type 95H is new for LINK386; it has a Line Number Offset field
  727. of 32 bits rather than 16 bits.
  728.  
  729. Record Format
  730. -------------
  731.    
  732.    1    2      1 or 2  1 or 2     2          2 or 4       1
  733.    94   Record Base    Base       Line       Line Number  Checksum
  734.    or   Length Group   Segment    Number     Offset       
  735.    95
  736.                                   <--------repeated------>
  737.  
  738. Base Group and Base Segment Fields
  739. ----------------------------------
  740.  
  741. The Base Group and Base Segment fields are indexes specifying
  742. previously defined GRPDEF and SEGDEF records. The Base Group field is
  743. ignored, and the Base Segment field must be nonzero.
  744.  
  745. Although the complete Intel specification allows the Base Group and
  746. Base Segment fields to refer to a group or to an absolute segment as
  747. well as to a relocatable segment, Microsoft restricts references in
  748. this field to relocatable segments.
  749.  
  750. Line Number and Line Number Offset Fields
  751. -----------------------------------------
  752.  
  753. The Line Number field is a 16-bit quantity, in the range 0 through
  754. 7FFF and is, as its name indicates, a line number in the source code.
  755. The Line Number Offset field is a 2- or 4-byte quantity that gives the
  756. translated code or data's start byte in the program segment defined by
  757. the SEGDEF index (4 bytes if the record type is 95H; 2 bytes for type
  758. 94H).
  759.  
  760. The Line Number and Line Number Offset fields can be repeated, so a
  761. single LINNUM record can specify multiple line numbers in the same
  762. segment.
  763.  
  764. Line Number 0 has a special meaning: it is used for the offset of the
  765. first byte after the end of the function. This is done so that the
  766. length of the last line (in bytes) can be determined.
  767.   
  768.   NOTES
  769.   
  770.   The source file corresponding to a line number group is determined
  771.   from the THEADR record.
  772.   
  773.   Any LINNUM records in an object module must appear after the SEGDEF
  774.   records to which they refer. Because LINNUM records are not
  775.   themselves referenced by any other type of object record, they are
  776.   generally placed near the end of an object module.
  777.   
  778.   Also see the INCDEF record of this document, which is used to
  779.   maintain line numbers after incremental compilation.
  780.  
  781. Examples
  782. --------
  783.  
  784. The following LINNUM record was generated by the Microsoft C Compiler:
  785.  
  786.      0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  
  787. 0000 94 0F 00 00 01 02 00 00 00 03 00 08 00 04 00 0F ...........
  788. 0010 00 3C                                           ..
  789.  
  790. Byte 00H contains 94H, indicating that this is a LINNUM record.
  791.  
  792. Bytes 01-02H contain 000FH, the length of the remainder of the record.
  793.  
  794. Bytes 03-04H represent the Base Group and Base Segment fields. Byte
  795. 03H (the Base Group field) contains 00H, as it must. Byte 04H (the
  796. Base Segment field) contains 01H, indicating that the line numbers in
  797. this LINNUM record refer to code in the segment defined in the first
  798. SEGDEF record in this object module.
  799.  
  800. Bytes 05-06H (the Line Number field) contain 0002H, and bytes 07-08H
  801. (the Line Number Offset field) contain 0000H. Together, they indicate
  802. that source-code line number 0002 corresponds to offset 0000H in the
  803. segment indicated in the Base Group and Base Segment fields.
  804.  
  805. Similarly, the two pairs of Line Number and Line Number Offset fields
  806. in bytes 09-10H specify that line number 0003 corresponds to offset
  807. 0008H and that line number 0004 corresponds to offset 000FH.
  808.  
  809. Byte 11H contains the Checksum field, 3CH.
  810.